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DNS Encoding of Geographical Location 
Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. This memo does not specify an Internet standard of any 
kind. Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Abstract 


This document defines the format of a new Resource Record (RR) for 
the Domain Naming System (DNS), and reserves a corresponding DNS type 
mnemonic and numerical code. This definition deals with associating 
geographical host location mappings to host names within a domain. 
The data shown in this document is fictitious and does not 
necessarily reflect the real Internet. 


1. Introduction 


It has been a long standing problem to relate IP numbers to 
geographical locations. The availability of Geographical location 
information has immediate applications in network management. Such 
information can be used to supplement the data already provided by 
utilities such as whois [Har85], traceroute [VJ89], and nslookup 
[UCB89]. The usefulness and functionality of these already widely 
used tools would be greatly enhanced by the provision of reliable 
geographical location information. 


The ideal way to manage and maintain a database of information, such 
as geographical location of internet hosts, is to delegate 
responsibility to local domain administrators. A large distributed 
database could be implemented with a simple mechanism for updating 
the local information. A query mechanism also has to be available 
for checking local entries, as well as inquiring about data from 
non-local domains. 
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2. Background 


The Internet continues to grow at an ever increasing rate with IP 
numbers allocated on a first-come-first-serve basis. Deciding when 
and how to setup a database of geographical information about 
internet hosts presented a number of options. The uumap project 
[UU85] was the first serious attempt to collect geographical location 
data from sites and store it centrally. This project met with 
limited success because of the difficulty in maintaining and updating 
a large central database. Another problem was the lack of tools for 
the checking the data supplied, this problem resulted in some 
erroneous data entering the database. 


2.1 SNMP: 


Using an SNMP get request on the sysLocation MIB (Management 
Information Base) variable was also an option, however this would 
require the host to be running an appropriate agent with public read 
access. It was also felt that MIB data should reflect local 
management data (e.g., "this" host is on level 5 room 74) rather than 
a hosts geographical position. This view is supported in the 
examples given in literature in this area [ROSE91]. 


2.2 X500: 


The X.500 Directory service [X.500.88] defined as part of the ISO 
standards also appears as a potential provider of geographical 
location data. However due to the limited implementations of this 
service it was decided to defer this until this service gains wider 
use and acceptance within the Internet community. 


2.3 BIND: 


The DNS [Mock87a] [Mock87b] represents an existing system ideally 
suited to the provision of host specific information. The DNS is a 
widely used and well-understood mechanism for providing a distributed 
database of such information and its extensible nature allows it to 
be used to disseminate virtually any information. The most commonly 
used DNS implementation is the Berkeley Internet Name Domain server 
BIND [UCB89]. The information we wished to make available needed to 
be updated locally but available globally; a perfect match with the 
services provided by the DNS. Current DNS servers provide a variety 
of useful information about hosts in their domain but lack the 
ability to report a host’s geographical location. 
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RDATA Format 


MSB LSB 
+--—+--4+--+--4+--+--4+--4+--4+--4+--4+--4+--4+--4+--4+--4+ 
/ LONGITUDE / 
+--—+--4+--+--4+--4+--4+--+--4+--4+--4+--4+--+4+--4+--4+--4+ 
/ LATITUDE / 
+-—+--4+--+--4+--+--4+--4+--4+--4+--4+--4+--4+--4+--4+--4+ 
/ ALTITUDE / 


+--+4+--+--+--+--+--+--+--+--4+--+--4+--+--4+--+--+ 
where: 


LONGITUDE The real number describing the longitude encoded as a 
printable string. The precision is limited by 256 charcters 
within the range -90..90 degrees. Positive numbers 
indicate locations north of the equator. 


LATITUDE The real number describing the latitude encoded as a 
printable string. The precision is limited by 256 charcters 
within the range -180..180 degrees. Positive numbers 
indicate locations east of the prime meridian. 


ALTITUDE The real number describing the altitude (in meters) from 
mean sea-level encoded as a printable string. The precision 
is limited by 256 charcters. Positive numbers indicate 
locations above mean sea-level. 


Latitude/Longitude/Altitude values are encoded as strings as to avoid 
the precision limitations imposed by encoding as unsigned integers. 
Although this might not be considered optimal, it allows for a very 
high degree of precision with an acceptable average encoded record 
length. 


The GPOS RR 


The geographical location is defined with the mnemonic GPOS and type 
code 27. 


GPOS has the following format: 
<owner> <ttl> <class> GPOS <longitude> <latitude> <altitude> 


A floating point format was chosen to specify geographical locations 
for reasons of simplicity. This also guarantees a concise 
unambiguous description of a location by enforcing three compulsory 
numerical values to be specified. 
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The owner, ttl, and class fields are optional and default to the last 
defined value if omitted. The longitude is a floating point number 
ranging from -90 to 90 with positive values indicating locations 
north of the equator. For example Perth, Western Australia is 
located at 32^ 7` 19" south of the equator which would be specified 
as —-32.68820. The latitude is a number ranging from -180.0 to 180.0. 
For example Perth, Western Australia is located at 116% 2’ 25" east 
of the prime meridian which would be specified as 116.86520. Curtin 
University, Perth is also 10 meters above sea-level. 


The valid GPOS record for a host at Curtin University in Perth 
Western Australia would therefore be: 


GPOS -32.6882 116.8652 10.0 


There is no limit imposed on the number of decimal places, although 
the length of the encoded string is limited to 256 characters for 
each field. It is also suggested that administrators limit their 
entries to the minimum number of necessary characters in each field. 


Master File Format 

Each host requires its own GPOS field in the corresponding DNS RR to 
explicitly specify its geographical location and altitude. If the 
GPOS field is omitted, a DNS enquiry will return no position 


information for that host. 


Consider the following example: 


; Authoritative data for cs.curtin.edu.au. 


r 


@ 


mar 


ftp 


Far 


IN SOA marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au. 

( 
94070503 ; Serial (yymmddnn) 
10800 ; Refresh (3 hours) 
3600 ; Retry (1 hour) 
3600000 ; Expire (1000 hours) 
86400 ; Minimum (24 hours) 

) 

IN NS marsh.cs.curtin.edu.au. 

sh IN A 13472421 

IN MX (0) marsh 

IN HINFO SGI-Indigo IRIX-4.0.5F 

IN GPOS -32.6882 116.8652 10.0 

IN CNAME marsh 
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lillee 


hinault 


merckx 


ambrose 
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A 134.7.1.2 

MX 0 marsh 

HINFO SGI-Indigo IRIX-4.0.5F 
GPOS -32.6882 116.8652 10.0 
A 134) 72d. 223 

MX 0 marsh 

HINFO SUN-IPC SunOS-4.1.3 
GPOS -22.6882 116.8652 250.0 
A 134.7.1.24 

MX 0 marsh 

HINFO SUN-IPC SunOS-4.1.1 

A 1345.7 s1499 

MX 0 marsh 

HINFO SGI-CHALLENGE_L IRIX-5.2 
GPOS -32.6882 116.8652 10.0 


November 1994 


The hosts marsh, lillee, and ambrose are all at the same geographical 


location, 


Perth Western Australia 
hinault is at a different geographical location, 


(-32.68820 116.86520). 
10 degrees north of 


The host 


Perth in the mountains (-22.6882 116.8652 250.0). For security 
reasons we do not wish to give the location of the host merckx. 


Although the GPOS clause is not a standard entry within BIND 


configuration files, 


whatever is not understood upon startup of the DNS. 
will result in a number of warnings appearing in system log files, 
but in no way alters naming information or impedes the DNS from 

performing its normal duties. 
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most vendor implementations seem to ignore 
Usually this 
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8. Security Considerations 


Once information has been entered into the DNS, it is considered 
public. 
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